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A Prototype  Implementation  of  d 
Protocol  for  Network  Security 

The  devel ooment  of  a protocol  which  achieves 
network  security  at.  the  level  of  the  commun  icat  ions 
svstem  by  dynamic  process  renaminq  has  proceeded  in  two 
staqes.  First,  the  protocol  was  subjected  to  modelling 
and  simulation  which  exposed  misconceptions  about  the 
loqical  operation  of  the  protocol.  The  results  of  this 
phase  are  summarized  in  (1,2).  This  paper  reports  on 
the  second  phase  of  development  in  which  a prototype 
system  was  created  on  the  Distributed  Computer 
Svstem(DCS)  at  the  University  of  California  at  Irvine. 
The  prototype  was  created  for  the  purpose  of  testinq 
the  protocol  in  a reasonably  realistic  environment.  It 
is  assumed  throughout  the  paper  that  the  reader  is 
familiar  with  the  protocol  as  presented  by  Farber  and 
I.ar  son  in  ( 1 | . 

This  report  is  div  idl'd  into  three1  sections.  The 
first  describes  t he  PCS  environment  and  its  impact  on 
iesign  decisions  made1  during  the  tmpl  ementat  ion  of  the 
prototype.  The  second  describes  the  prototype 
impi ementation  showinq  the  close  rel ationship  between 
the  protocol  as  modelled  for  analysis  and  the  pcotocol 
prototype  impi  ('mentation.  The  final  section  summarizes 
* he  changes  necessary  to  fully  integrate  the  protocol 


prototype  implementation  into  the  DCS  operating  svstem 
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T 


('nvironment  and  suqqests  .1  de-siqn  for  a more  flexible 
implementation  of  the  protocol. 


The  PCS  Environment 

The  PCS  net  is  composed  of  three  Lockheed  SUE 
computers  inter commun icatinq  over  a unidirectional  data 
cinq.  The  SUE  computers  are  interfaced  to  the  rinq 
throuqh  a special  communications  device  called  a rinq 
1 riter  f act'  ( R 1 ) as  shown  in  Fiqure  1.  All  interprocess 
commun icat 10ns  are  messaqe  based.  Messaqes  on  the  rinq 
utilize  process  names  rather  than  fixed  hardware  RI 
addresses  as  the  messaqe  destination.  This  capability 
is  achieved  by  includinq  an  associative  store  which 
functions  as  a process  name  table  in  each  RI.  When  a 
messaqe  is  received,  the  RI  matches  the  destination 
address  aqainst  the  process  name  table  to  determine  if 
the  destination  process  is  resident  on  the  attached 
host  (SUE)  . The  PCS  Software'  system  is  not  machine 
dependent  except  for  two  processes: 

1)  the  nucleus  process  which  provides  process 
schedulmq  and  messaqe'  rontinq  facilities  for 
the  local  ii'Side'nt  proce'SSe'S 
and 
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2) 


the  I/O  handler  process 
interface  between  the 


which  provides  an 


inter  process 


message 


system  and  the  local  I/O  devices  on  that  SUE. 


The  protocol  under  study  is  desiqned  to  supply 
security  it  the  site  to  site  level  but  not  necessarily 
at  the  interprocess  commun icat ions  level  within  the 
host  computers,  although  future  investigations  of  the 
protocol  may  show  that  it  is  suitable  for  security  at 
this  level  also.  The  current  design  is  based  on  the 
existence  ot  a separate  communications  processor  which 
interfaces  the  host (SUE)  to  the  communications  system. 
The  R 1 provides  this  service  in  the  DCS  environment, 
but  the  current  R1  cannot  be  programmed  or  easily 
modified.  Thus,  it  is  necessary  to  simulate  the 
commun icat ions  processor  in  software  as  a collection  of 
site  bound  processes  within  each  SUE.  In  the  early 
stages,  it  was  hoped  that  these  processes  might  use  the 
RI  name  jble  to  eliminate  unwanted  messages  by  placinq 
the  receive  names  in  the  table.  The  name  table, 
however,  has  only  sixteen  positions  as  manv  as  six  of 
which  are  consumed  bv  system  processes.  There  are  too 
few  remaining  positions  to  support  more  than  two 
send-receive  links;  thus,  no  effort  is  made  to  utilize 
the  RI  process  name  table. 


The  DCS  operatinq  system  is  not  desiqned  to 
interface  to  the  simulated  rommun icat ions  processor.  A 
user  process  called  LI  can  be  used  within  the  current 
prototype  svstem  to  link  to  a "distant  site".  DCS, 
however,  does  not  currently  recognize  the  protocol 
control  process  (PCP)  as  a handler  of  the  user  teletype 
or  terminal  and  will  not  transfer  the  name  of  the 
protocol  control  process  to  the  created  user  process. 
As  a result,  a special  user  process  hoS  been  created 
strictly  for  testinq  purposes.  Changes  to  the  DCS 
operating  system  which  would  allow  total  integration  of 
t he  simulated  communications  processor  are  discussed  in 
the  f inal  sect  ion  . 


The  Prototype  Protocol  Implementation 

The  prototype  implementation  of  the  protocol 
centers  on  the  simulated  communicat ions  processor.  The 
simulated  comrnun ications  processor  is  formed  from  two 
processes:  1)  the  protocol  control  process  (PCP)  which 
ir  an  impl  ement at  ion  of  the  protocol  ar.d  2)  NETP  which 
simulates  hardware  functions,  performs  allocation,  and 
provides  testinq  aids. 
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NETP  is  responsible  for  allocation  of  the  channels 
throuqh  which  processes  can  communicate  with  other 
hosts  and  the  filtering  and  routing  of  messages.  When 
NETP  receives  a request  to  open  a channel  to  another 
host,  it  assigns  a protocol  control  processes  to  the 
channel,  informs  the  PCP  of  the  user  (requestor) 
process  name,  and  sends  the  user  process  the  name  of 
the  PCP  assiqned.  It  also  records  in  the  channel  table 
the  destination  host  and  throughout  the  duration  of  the 
link  maintains  current  entries  of  RN,  ORN,  and  OORN  as 
discussed  in  ( 1 ] . These  entries  are  used  to  simulate 
the  R I functions  and  refuse  messages  which  are  not 
addressed  to  a valid  process  name.  The  entries  also 
provide  a means  of  routing  incominq  net  messages  to  the 
correct  PCP  process.  All  prototype  communication  over 
the  ring  is  from  a NETP  at  one  host  to  a NETP  at 
another  host.  NETP  can  be  thought  of  as  the  "system" 
process  necessary  in  a communications  processor. 

PCP  is  a direct  implementation  of  the  protocol  as 
modelled  (21.  PCP  operates  as  a state  machine  with 
four  states  determined  by  two  binary  variables  WTMSG 
and  WTRSP . When  both  variables  are  zero  (SEND)  there 
are  no  messages  expected  from  the  net,  i.e.  no 
messaqes  sent  for  which  a response  has  not  been 
received.  in  this  state  PCP  waits  for  a message  from 
the  user  process  on  the  local  host.  If  a reset  message 
is  received  from  the  other  PCP  on  the  link,  indicating 
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the  othi  r PCP  is  testing  the  link,  an  OK  message  is 
returned  to  mountain  synchron  ization . when  a message 
is  received  from  the  user,  the  PCP  reformats  the 
message  and  sends  it  to  the  local  NETP  which  forwards 
the  message  to  the  NETP  at  the  other  host  as  dictated 
by  the  chanmd  . The  PCP  sets  the  binary  variable  V/TMSG 
and  enters  a state  in  which  it  waits  for  the  response 
trom  the  other  host.  If  the  PCP  receives  the  returned 
message  before  a timeout  occurs,  it  reformats  the 
message  and  passes  it  to  the  user.  The  PCP  then  resets 
WTMSG  and  returns  to  the  initial  state  to  wait  for  a 
user  response.  If  the  PCP  does  not  receive  a response 
before  a timeout  occurs,  the  PCP  sends  a reset  message 
to  the  other  PCP  to  test  the  link  and  sets  WTRSP  to 
indicate  that  a response  is  expected  from  the  PCP  at 
t ho  other  host.  When  a normal  message  or  response 


( reset-response 

or 

OK) 

message  is 

received  the 

associated  var  table 

is 

se  t 

to 

zero  to 

indicate  the 

expected  response 

wa 

s r 

ece 

ived  , 

II  both 

are  not  set  to 

zero  be  for*'  t he  * 

nd 

of 

t he 

next 

timeout 

oeriod,  a major 

network  failure  is  assumed  and  the  PCP  sends  a "close" 
nw  ssuge  to  both  the  user  process  and  NETP.  NETP  closes 
the  channel  by  deleting  the  context  associated  with  the 
channel . 

The  us*'  of  a separate  PCP  for  each  channel  is 
chosen  because  the  resulting  cod*'  is  more  readable  and 
easily  understood  than  it  would  he  if  the  process 
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multiplexed  among  the  various  channels.  It  also 
eliminates  reproducing  functions  already  present  in  the 
operating  system.  With  future  proposed  modifications 
*o  the  DCS  software,  it  may  he  possible  to  use  a single 
re-entrant  instance  of  a PCP.  In  the  final  section,  a 
similar  implementation  is  proposed  for  future 
commun icat ions  processor  based  designs. 


System  Operation 

The  current  system  operates  as  a vehicle  for 
testing  of  the  protocol.  The  prototype  is  comprised  of 
tour  maior  processes.  LI  provides  a means  of  linking  a 
teletype  to  another  host.  FCHO  is  the  only  user 
process  currently  available  at  other  hosts.  It  returns 
the  user  message  after  waiting  for  a predetermined 
length  of  time.  N’FTP  provides  debugging  and  statistics 
gathering  facilities.  With  these  facilities  on*'  can 
pr int  the  messages  sent  and  received  by  NETP  and  record 
t he  number  ot  messages  processed  of  each  type:  normal, 
reset,  r eset-cesponse  and  OK.  A feature  also  computes 
an  "average  response  t ime"  which  is  based  on  the 
aver  age  length  ot  time  between  the  transmission  of  a 
message  by  a channel  and  the  receipt  of  a repsonse 
message  by  that  channel . The  protocol  control  process 
( PC P 1 is  a direct  impl ement at  ion  of  the  protocol  as 
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dt'scr  ibed . 

The  test  plan  is  simple.  Observation  of  the 
messaqe  scripts  generated  by  NETP  durinq  the  operation 
of  the  prototype  shows  that  the  protocol  operates  as 
predicted  by  Farber  and  Larsonfl].  The  message 
addresses  are  generated  by  a pseudo-r andom  number 
generator  and  exhibit  a suitable  degree  of  randomness. 
By  varying  the  parameter  in  ECHO  the  message  load  rate 
can  be  changed.  By  varying  a parameter  in  NETP  an 
artificial  ring  error  rate  can  be  induced  if  the  ring 
does  not  supply  sufficient  errors.  NETP  can  be  used  to 
monitor  the  protocol  response  time  under  the  various 
conditions  of  message  load  and  ring  error  rates.  This 
information  provides  a basis  for  determining  timeout 
periods  and  an  idea  of  expected  performance  under 
various  conditions.  The  results  follow  the  expected 
curve  in  which  the  rate  of  message  flow  on  the  network 
is  correlated  with  the  inverse  of  the  delay  in  the  user 
processes  (ECHO  and  LINK).  The  relationship  follows 
the  dashed  line  in  Figure  2.  Since  the  bandwidth  of 
the  ring  hardware  is  sufficient  to  handle  any  load 
created  by  the  three  hosts,  there  is  no  problem  with 
interference  from  erroneous  reset  and  response 
(reset-response  and  OK)  messages.  Thus,  the  waiting 
period  for  a timeout  can  be  fixed  at  any  reasonable 
length  which  is  greater  than  the  delay  in  the  processes 
ECHO  and  I, INK  without  significant  effect  on  the  message 


rate.  This  is  not  necessarily  char actec istic  of  dll 
networks. 


To  gain  a general  picture  of  the  expected 
performance  of  the  protocol  on  other  networks,  the 
protocol  is  simulated  as  a Markov  process  in  which  time 
is  divided  into  short  intervals  called  epochs.  The 
simulation  of  interprocess  message  traffic  involves 
f ive  pairs  of  commun icating  processes.  Messages  are 
queued  for  transmission  on  the  network  in  a strict 
f lr st-come- fir st-served  manner  on  a network 
transmission  queue  at  each  host.  The  expected  number 
of  epochs  that  a message  must  wait  for  service  from  the 
net  is  defined  by  a parameter,  OLOAD,  i.e.  the 
probability  that  a message  is  removed  from  the  queue 
and  transmitted  to  the  destination  process  is  given  by 
1/OLOAD.  The  transmission  of  the  message  from  the 
network  queue  at  one  host  to  a process  at  another  host 
is  assumed  to  take  a negligible  amount  of  time  and 
modt>ll  ed  as  if  it  is  instantaneous  once  the  message  is 
serviced  from  the  network  queue.  A Parameter  LOAD 
determines  the  expected  length  of  time  that  a message 
is  processed  in  a user  process  before  the  process  sends 
a message  to  the  local  network  queue  for  transmission 
to  the  associated  process  at  the'  other  host.  Thus,  if 
a process  has  received  a message,  the  probability  that 
the  process  passes  the  leturn  message  to  the  network 
queue  during  an  ensuing  epoch  is  given  by  1/LOAD. 
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The  results  of  the  simulation  act'  shown  in 

KMiirr  2.  The  verticle  axis  rt'pct'sonts  tht'  messaqe 
flow  as  a pec  I'ent  aqe  of  a "maximal"  flow  which  would 
occur  if  .1  messaqe  wore  processed  each  epoch.  The 

horizontal  axis  represents  the  LOAD  parameter  in 
epochs.  Tin*  par  ami'  ter  OLOAP  is  fixed  at.  2,  and  the 
number  ot  epochs  before  a timeout  can  occur  and  a reset 
messaqe  is  oencrated  is  fixed  at  32.  The  reset  and 
response  messages  suffer  from  queuinq  delay  but  since 
they  ue  processed  in  the  commun  icat  ions  processor, 
they  suffer  no  delay  at  the  host.  In  the  qraph  the 

solid  line  represents  the  simulated  messaqe  flow.  The 
broken  line  represents  the  optimal  messaqe  flow  which 
occurs  it  reset  messaqes  are  never  qenerated  and  no 
messaqes  are  lost.  The  difference  between  the  broken 
line  and  the  solid  line  represents  the  loss  of 
bandwidth  due  to  network  errors  and  tho  interference 
created  by  reset  and  response  messaqes.  The  messaqe 
flow  is  said  to  saturate  at  a specific  value  of  LOAD, 
if  as  the  t.OAD  increases  beyond  that  value,  the  messaqe 
rate  does  not  s iq n.i f icant  1 y decrease.  In  the  qraph  the 
protocol  saturates  with  messaqes  at  about  t.0AP*2r'. 
This  is  also  true  when  the  simulation  is  run  with  a 
simulated  rate  of  messaqe  loss  of  r>»  and  Id*.  In  .ill 
cases , the  saturation  occurs  at  nearly  the  same  value 
of  t.OAP.  While  the  simulated  messaqe  loss  does  not 
effect  the  value  of  l.OAP  at  which  saturation  is 


reached,  it  does  reduce  the  rate  of  message  flow  pr  ioc 
to  saturation  hy  a percentage  roughly  equal  to  the 
simulated  rate  of  message  loss,  as  would  be  expected. 
Message  loss  does  not,  however , appreciably  effect  the 
rate  of  message  flow  once  saturation  has  been  reached. 


Future  Plans 

The  total  integration  of  the  protocol  prototype 
into  the  DCS  operating  system  can  be  achieved  in  a 
"natural"  way.  In  implementing  the  protocol  contcol 
process,  it  was  observed  that  pep  resembles  the  I/O 
handler  process  of  DCS.  With  minor  modifications  the 
PCP  can  easily  function  as  a pseudo-I/O  handler  as 
shown  in  Figure  3.  The  PCP  need  only  recognize  control 
commands  sent  to  the  I/O  handler  such  as  those  which 
close  the  connection  with  the  device  or  transfer  the 
device  to  another  process;  the  other  messages  can  be 
passed  to  the  actual  I/O  handler  at  the  othec  host. 
The  recognition  of  control  commands  could  be 
implemented  presently  if  the  system  process  which  loads 
user  processes  would  recognize  the  protocol  control 


pr  ocesse 

s as  I/O 

handlers  and  pass  the  name  of 

the 

PCP 

as 

the 

name  of 

the  user's  terminal  interface 

process. 

In 

t hi' 

current 

environment  user  processes 

can 

bo 

cr  t 

'dted 

at  othe 

r hosts,  hut  the  usee  terminal 

Wll  1 

not 

he 

conne 

cted  to 

the  process.  The  DCS  system  is 

in 

the 

process  o t minor  changes  and  until  the  shape  of  the  new 
system  is  completely  determined  no  attempt  will  he  made 
to  effect  the  change. 

The  prototype  implementation  in  use  is  suited  to 
DCS,  hut  the  protocol  could  he  implemented  in  a more 
structured  and  efficient  fashion  on  a dedicated 
commun i cat  ions  processor.  As  described  previously,  t he 
protocol  is  implemented  as  a state  machine.  The  state 
of  a channel  can  be  determined  by  three  binary 
variables:  WTUSER,  WTMSG , and  WTRSP.  WTUSER  indicates 
that  a message  is  expected  from  the  user,  and  there  are 
no  messages  expected  from  the  net  (WRSP*0  and  WTM SG*Q). 
WTMSG  indicates  that  a mess, me  was  sent  to  another 
host,  but  no  message  has  been  received  in  return,  so  a 
mess. me  ;s  expected  from  the  net.  WTRSP  indicates  that 
a reset  message  was  sent  and  a r eset-rosponse  is 
expected  but  has  not  yet  been  received.  The  state 
changes  are  caused  by  receiving  a specific  message 
format.  Due  to  the  lock  of  a separata'  communications 
processor,  the  PCS  prototype  implementation  required 
"everal  environmentally  dependent  features.  The  R1 
name  table  is  insufficient  so  routtnq  and  validation  of 
dost  mat  ion  names  must  be  done  in  software.  This 
requires  the  extra  "destination"  header,  since  all 
messages  are  addressed  to  t ho  router  process  NETP. 
Since  ,i  premium  is  placed  on  the  number  of  processes 


created,  (he  router  is  al so  used  to  assign  processes  to 
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channels,  although  a se'parate  protocol  control  process, 
POP,  is  used  for  each  channel.  The  router  must  also 
update  the  simulated  name  tables. 

The  DCS  prototype  functions  adaquately  in  the  DCS 
env lr onment , hut  a much  "cleaner”  design  of  a prototype 
implementation  is  shown  in  Figure  4.  With  an  expanded 
RI  name  table,  the  RI  could  validate  names.  The 
current  NFTP  functions  can  he  separated  into  four 
procedures:  1)  the  allocation  and  deallocation  of 
channels,  2)  the  router  which  determines  the  "class"  of 
the  message  and  routes  the  message  and  the  appropriate 
channel  entry  to  the  correct  processing  element,  3)  the 
clock  process  which  manages  timeouts  for  the  various 
channels  and  routes  messaqes  with  the  correct  channel 
table  entry  to  the  appropriate  processing  element  when 
a timeout  occurs,  and  4)  an  update  process  which 
manages  the  hardware  and  software (channel ) name  tables. 
For  each  transition  defined  m the  protocol  there  is  a 


processing  element  which  takes  a mossaqe  and  a channel 
table'  entry,  performs  the  required  processing 
associated  with  the'  transition,  modifies  the'  channel 
table  entry  accordingly  including  the'  state'  variable's, 
and  passes  a message'  to  e\ithe>r  one'  of  the  previously 
de'scribed  NFTP  processing  e'le>me'nts  or  the'  user  process. 
This  desiqn  can  increase  e'fficie>ncy  by  allowing  more 
processing  e'le'me'nts  of  a needed  type'  to  be  adde'd , 


w 1 1 hout 


crediting  unnecessary  e'le'me'nts  which  may  not 
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used,  an  happens  when  a complete  process  is  assigned  to 
each  channel  . It  also  provides  a natural  setting  for 
mul tiprocess ing . If  a "hank"  of  microprocessors  is 
available,  each  unit  can  be  assigned  the  function  of  a 
processing  element.  If  more  processing  elements  of  a 
specific  tyne  are  necessary,  more  processors  can  be 
assigned  that  function.  The  router  provides 
synchronization  and  may  prove'  to  be  the  limiting  factor 
in  such  a system. 
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